060 Причины и тригеры сбоев

Слайды на отдельной странице

О чем лекция

1. Откуда берутся сбои
2. Триггеры сбоев
3. Причины сбоев
4. Необвинительная культура в SRE

SRE инженеры работают со сбоями. И поэтому важно понимать источники сбоев и уметь правильно находить причины конкретных сбоев у вас в компании.

Источники сбоев мы будем делить на триггеры и причины сбоев.

Триггеры сбоя

Триггер сбоя — непосредственно, то событие с которого началось влияние сбоя на пользователей. Триггер может одновременно являть причиной сбоя, но часто триггер и причина, а вернее причины сбоя, — это совершенно разные вещи.

Чтобы произошел сбой, должно что-то произойти внутри или во вне системы. Давайте посмотрим на весь список возможных триггеров сбоев, а затем рассмотрим подробно каждый.

Классификация триггеров сбоев:

Классификация триггеров сбоев

1. стихия или внешние техногенные факторы,
2. релизы,
3. отказы оборудования,
4. изменения в действиях пользователей в т.ч. рост нагрузки,
5. переполнение,
6. срабатывание бага, который проявляется в случайное время,
7. изменения в работе внешних систем,
8. действия администраторов (обученных сотрудников компании),
9. действия третьих лиц

Cтихия или внешние техногенные факторы

Сюда относятся землетрясения, наводнения, обрушения конструкций, пожары и другие факторы. Внезапное воздействие такой силы очевидно может привести с сбою вашей информационный системы. И здесь мало что можно поделать... если у вас нет множества гео-распределеденный датацентров или вы хоститесь в таком клауде.

Релизы

TODO(d.maslennikov)

Отказы оборудования

TODO(d.maslennikov)

Изменения в действиях пользователей в т.ч. рост нагрузки

Сбой может быть вызван тем, что к вам пришло много пользователей и вы не успели смасштабироваться. Иногда пользователи могут прийти очень быстро и неожиданно. Достаточно вирусной новости про вас на очень популярном ресурсе и количество пользователей может возрасти в тысячи раз за день. Так же к резкому росту приводят рекламные компании.

Курьезный пример — резкий рост нагрузки на Google Assistаnt производят телевизионные рекламные ролики, где произносится фраза "Ok Google".

Переполнение

Сюда относится такая причина сбоев, как переполнение счетчиков в базах данных или в коде.

Другой источник: разрастание данных до пределов, которые ваши системы не могут обработать.

Например, вы генерировали какой-нибудь отчет, загружая все данные в оперативную память, но данных вдруг стало больше, чем вы можете выгрузить.

Другой пример реального сбоя: логи системы собирались со многих серверов на один по сети для дальнейшей обработки. С ростом системы пропускной способности сети того центрального сервера перестало хватать, чтобы принять все логи.

Изменения в действиях внешних систем

У нас есть интеграция с внешним сервисом. У него мог сучиться сбой и вызвать сбой у нас.

А может быть и так, что мы пользовались устаревшим (deprecated) методом и пропустили момент, когда его удалили.

Действия администраторов

Администраторы системы, обычно имеют доступ к оборудованию, операционным системы, административному интервейсу. У администраторов самый широкий набор возможностей по выведению сервиса из строя. Администраторы совершают рискованные действия. И часто от их действий создается менше защит, так как предполагается, что администратор — обученный профессионал. К сожалению, даже лучшие из нас ошибаются.

Действия третьих лиц

Хакеры, конкуренты, атаки. В реальном мире все это существует. Крупные бизнесы живут под атаками непрерывно. Для более мелких это может стать сюрпризом.

Причины сбоев

Кроме триггеров существуют причины сбоев. Причина сбоя это то, на что мы собираемся воздействовать, чтобы в дальнейшем подобных сбоев не возникало или они имели меньшие последствия.

Все причины мы поделим на

• контролируемые и
• неконтролируемые (те, что не хотим контролировать)

Контролируемые причины кроются так или иначе в человеческом поведении, так только это поддается нашему сознательному контролю.

Неконтролируемое

Некоторые причины сбоев крайне редки, так что мы сознательно никогда не будем на практике от них защищаться и даже пытаться воздействовать.

Для разных компаний это будут разные факторы. Это зависит от зрелости инженерной культуры, масштабности и специфики бизнеса компании.

Как правило к таким факторам относят:

Стихию и природные явления: наводнения, землетрясения и т.п. От этого вполне возможно защититься, так Google-поиск не перестанет работать после землетрясения, даже если оно полностью разрушит один датацентр Google, но для большинства компаний и бизнесов это будет черезмерно.

Техногенные факторы: пожары, обрушения конструкций, перебои в подаче электричества и подобное. Я знаю про случай, когда экскаватор копал траншею и перебил линию связи. От части таких факторов защита производится. Датацентры оборудуются системами пожаротушения. Дублируются источники электроэнергии, ставятся генераторы. И многое другое. Но и это может быть недостаточно или избыточно для части бизнесов.

примечание

Если вы хоститесь в публичном клауде в разных датацентрах и можете выдерживать пропадание одного из них, то вы весьма защищены и от стихии и от техногенных факторов.

Отказы оборудования: некоторое оборудование весьма надежно и для некоторых бизнесов допустимо принять решение, что мы надежны настолько, насколько надежно то или иное оборудование. То есть сознательно принимается решение, что отказ некоторого оборудования приведет к сбою на всей системе и это допустимо. Многие компании тем не менее често защищаются от поломок оборудования (иногда только части оборудования). Надо понимать, что чем больше у нас оборудования, тем чаще оно будет выходить из строя: один сервер будет ломаться один раз в несколько лет, но если у нас несколько тысяч серверов, то какие-то из них будут сломаны всегда и жить без кокой бы то ни было защиты от поломок оборудования будет нельзя.

Контролируемое

Контролируемые причины кроются так или иначе в человеческом поведении и есть огромное множество разных вариантов допустить сбой.

Прежде чем рассматривать сами причины внимательно проясним два понятия: ошибка и недоработка.

Ошибка

Ошибка — непосредственно ошибка человека. Очень часто в житейском применении этого слова имеют в виду разные вещи, которые не являются ошибкой: ситуация, когда человек не знал какой-либо информации и действовал неправильно из-за этого. Например, не читал документации, пропустил важное уведомление и т.п.

Ошибка это только когда человек знал и если обратил бы пристальное внимание на факт некорректного решения, то исправился бы.

Так, если вы редактировали конфигурацию в виде JSON файла и поставили лишнюю запятую после последнего элемента в списке, зная, что так делать нельзя — это ошибка.

Если вы редактировали конфигурацию в виде JSON файла и воспользовались опцией, которая больше не поддерживается приложением, так как информация о том, что эта опция больше не поддерживается прошла мимо вас — это НЕ ошибка.

Недоработка

Недоработка — это почти как ошибка в коде, но имеет под собой другую историю. Ошибка это кода код работает не так как надо, потому что вы ошиблись. Недоработка — это когда код не работает так, как надо, потому что вы еще не сделали, чтобы он работал так как надо.

Важно различать ошибки и недоработки (и то и то в просторечье может именоваться словом "баг"), так как причины появления тех и других разные. Недоработки свидетельствуют возможно о проблемах в приоритезации работ, нехватке ресурсов, слишком раннем выходе в прод еще неготового функционала. Ошибки же будут всегда и без наличия этих факторов.

Теперь пройдемся по причинам сбоев.

Ошибка или недоработка в программном коде, архитектуре и т.п.

Под кодом здесь мы имеем в виду все, что похоже на код: непосредственно программный код продуктов, Ansible playbooks, сложные конфигурационные файлы и т.п.

Ошибки разработчика — очень распространенная причина сбоев.

Такие ошибки проникают к нам разными путями. Это может быть внутренние разработчики. Это мог быть код открытого проекта. Или код мог быть разработан сторонней компанией и куплен нами.

Еще бывает так, что мы уже знали про данную проблему, но не успели починить и она вызвала сбой. Это очень плохая ситуация, и надо обязательно отслеживать количество сбоев вызванных уже известными проблемами.

Поэтому в классификации сбоев есть специальные подпункты для этих случаев.

Ошибка или недоработка в процессах работы

Сами процессы и процедуры работы могут быть устроены так, что даже при следовании им все равно могут порождаться сбои. В этом случае придется менять процесс.

Другой проблемой процессов может быть то, что следование ему настолько трудоемко, что администраторы или пользователи будут пытаться срезать путь.

Как и в случае ошибок и недоработок в программном коде мы можем знать, что процесс проблемный, но не успели обсудить и поменять его.

Ошибка сотрудника при проведении плановых или других работ по обслуживанию систем

Любые работы по обслуживанию вносят дополнительный риск для эксплуатируемых систем. Потому что инженер, обслуживающий систему, как правило обладает большими правами и возможностями по воздействию на систему и результат его действий может быть очень негативным.

Это породило один из анти-принципов: "работает — не трогай". Менять рано или поздно придется все. Если что-то долго не меняется, то мы теряем экспертизу в обслуживании данной системы. Наоборот, надо менять системы, как можно чаще — это в том числе повышает экспертизу компании в обслуживании систем и уменьшает количество сбоев связанных с обслуживанием.

Не следует путать ошибку сотрудника с "проблемной коммуникацией" — другой причиной сбоев. Ошибка, это когда человек знал, как действовать правильно, но ошибся. Совсем другой случай, когда человек не знал, как действовать правильно и потому совершил действие приведшее к сбою. У этих двух причин разные способы устранения. Так обучение работает только во втором случае, но не в первом. А вот написание плана работ помогает только в первом случае, но не во втором.

Иногда есть соблазн объявить причиной сбоя сам релиз — я встречал классификации причин сбоя, которые содержали такой пункт неоднократно. Это не правильно. Релиз — часть нормального зизненного цикла приложения и не может быть причиной сбоя, но только триггером.

Еще ошибки пользователя бывают вызваны неудачными интерфейсами. Бывает интерфейсы прямо подталкивают нас совершить ошибочное действие. Здесь я имею в виду все типы интерфейсов и графические и командной строки и любые другие. Для графических интерфейсов это может быть отсутствие подтверждения на выполнение опасных действий. Менее очевидное подталкивание к ошибке это когда подтверждение на очень опасную операцию выглядит точно так же, как подтверждение на часто выполняемую менее опасную операцию, и пользователь вырабатывает привычку быстро подтверждать действие не думая. Последнее мможно починить, сделав 10-секундную задержку перед возможностью подтвердить очень опасное действие. Это выделит опасный запрос и даже защитит, если пользователь все-таки щелкнул на автомате в неактивную кнопку. В классификацию сбоев мы так же добавим специальный подпункт для таких случаев.

Ошибка при использовании сервиса

В данном случае неверное действие совершает не команда специально обученных администраторов, а пользователи сервиса.

Хороший сервис должен быть защищен от некорректных действий пользователей. Но иногда из-за черезмерной сложности такие защиты намеренно не делаются и мы полагаемся на обучение пользователя. Чаще это верно для внутренних пользователей компании или для пользователей-профессионалов. Например, пользователи Postgres сервиса скорее всего будут программистами-профессионалами и данный сервис сложно будет защитить от их ошибок, например множества fullscan запросов по данным без индексов, которые приведут к отказу сервиса.

Обратите внимание, что пример с Postgres может быть, как ошибкой, так и проблемой в коммуникации. Например, пользователь был уверен, что там есть индекс, но индексы недавно поменяли в результате рефакторинга и не всех уведомили — это уже не ошибка пользователя, а именно проблемная коммуникация.

Как и в предыдущем случае пользовательский интерфейс может подталкивать пользователей к ошибочным действиям.

Проблемная коммуникация между людьми

Очень комплексный источник сбоев. Включает множество под-причин. Сюда относится отсутствие документации или части информации в документации. Недостаточность обучения или неэффективность обучения. Люди могут некорректно поставить или понять задачи. Люди могут нечетко объяснить или понять, какие либо важные детали. Мы можем не послать важное уведомление правильному адресату, или мы можем перегрузить сотрудников валом уведомлений и они начнут пропускать важные. Коммуникация — важный источник проблем, которые приводят к сбоям. SRE надо обязательно хорошо разбираться в коммуникации и уметь выстаивать правильную коммуникацию внутри команды, с соседними командами и с пользователями систем.

Прямая системная человеческая проблема (выгорание, депрессия, системная неудовлетворенность работой, конфликты и т.п.)

Этими проблемами занимаемся не мы (SRE), а скорее HR и психологи. Тем не менее полезно помнить, что такие системные проблемы будут приводить к сбоям, как бы хорошо мы ни поработали над остальными пунктами.

Умышленное приченение вреда

К несчастью бывает и такое что сотрудники компании или третьи лица могут намеренно вывести ваш сервис из строя. В современном мире атаки на популярные крупные сервисы идут практически непрерывно. Намеренное вредительство изнутри встречается реже и хоть и может быть причиной сбоя, скорее относится к ведению информационной безопасности, а не SRE.

SRE должны принимать во внимание вопросы защиты от DDOS атак, а так же вопросы разработки средств восстановления после любых сбоев включая намеренное вредительство. Сейчас популярны шифровальщики данных, которые могут испортить ваши данные ради выкупа. Организации атакуют ради этого не реже частных лиц.

Недокументированное отклонения в работе внешнего сервиса

Сейчас очень популярны сервисы. То есть когда вы не работаете с кодом самостоятельно, а только взаимодействуете с ним по сети. Если произошел сбой вызванный отклонениями в работе сервиса от которого вы зависите, то там сработали одна или несколько из описанных выше причин. Но скорее всего вы не узнаете какая именно. Поэтому разумно выделить отдельный класс причин сбоев — сбой в результате проблем во внешнем — то есть на который не можем повлиять — сервисе.

warning

Сервис, который обслуживает другая команда в вашей компании, не является внешним!

Почему "недокументированное"? Потому что если такая работа сервиса была документирована, но мы не знали, то это уже другая причина, а именно — проблемная коммуникация между людьми. И она имеет другие средства противодействия.

Классификация причин сбоев

Ниже представлена полная классификация причин сбоев:

Классификация причин сбоев

1. неконтролируемое
   1. стихийные бедствия (наводнения, землетрясения и т.п. — от них тоже можно защититься при достаточном количестве вложенных усилий)
   2. разрушения инфраструктуры (пожары, отключения электроэнергии, обрушения конструкций и т.п.)
   3. отказ IT оборудования (только, если мы сознательно решили не контролировать!)
2. контролируемое
   1. ошибка или недоработка в программном коде
      1. код разработан внутри компании
      2. код взят из открытого проекта
      3. код куплен у вендора
      4. техдолг, проблема была уже известна и решение тоже известно
      5. проблема известна, и мы не знаем, что с этим делать
      6. проблема абсолютно неожиданна, возникла в первый раз
   2. ошибка или недоработка в архитектуре приложения
      1. код разработан внутри компании
      2. код взят из открытого проекта
      3. код куплен у вендора
      4. техдолг, проблема была уже известна и решение тоже известно
      5. проблема известна, и мы не знаем, что с этим делать
      6. проблема абсолютно неожиданна, возникла в первый раз
   3. ошибка или недоработка в архитектуре системы приложений
      1. система разработана внутри компании
      2. система является открытым проектом
      3. система куплена у вендора
      4. техдолг, проблема была уже известна и решение тоже известно
      5. проблема известна, и мы не знаем, что с этим делать
      6. проблема абсолютно неожиданна, возникла в первый раз
   4. недоработка в процессах работы
      1. непосредственно ошибка в процессе
      2. процесс подталкивает сотрудника к неправильному поведению
      3. техдолг, проблема была уже известна и решение тоже известно
      4. проблема известна, и мы не знаем, что с этим делать
   5. ошибка сотрудника при проведении плановых или других работ по обслуживанию систем
      1. административный интерфейс или дизайн системы, провоцирующий ошибочные действия
   6. ошибка при использовании сервиса (отсутствие защиты от некорректного использования системы пользователями)
      1. пользовательский интерфейс, провоцирующий ошибочные действия
   7. проблемная коммуникация между людьми
      1. некорректно поставлена или понята задача
      2. некорректная документация
      3. неполучение важного уведомления
      4. недостаточное обучение
   8. игнорирование риска при желании достигнуть результата любой ценой
      1. игнорирование риска произошло при давлении от руководства
   9. прямая системная человеческая проблема (выгорание, депрессия, системная неудовлетворенность работой, конфликты и т.п.)
   10. умышленное причинение вреда (отсутствие защиты)
       1. сотрудником
       2. третьими лицами
   11. недокументированное отклонение в работе внешнего сервиса

Что не является причиной сбоя

Причинами сбоя часто пытаются назвать вещи, которые никогда не могут быть их причиной.

Два часто встречающихся примера: релиз приложения и аппаратная проблема (отказ железа).

Оба этих предмета не поддаются воздействию.

Приложения релизились, релизятся и будут релизиться. Причем как правило надо делать это часто. Это нормальная жизнь приложежения и релиз совсем не причина, чтобы что-то не работало. Релиз может быть только триггером сбоя. Причина или причины это что-то из вышеназванного, например, ошибка релиз-инженера или баг в приложении и именно на это мы будем воздействовать, а не на сами релизы.

Аппаратная проблема тоже не может быть причиной сбоя. Желозо всегда ломается и будет ломаться и это известно заранее. Поэтому мы либо выносим защиту от этого за скобки сознательно — то есть объявляем этот класс проблем форс-мажором (то есть не защищались от него и не собираемся), либо это недоработка в коде — нет защиты от аппаратных отказов.

Зато оба этих фактора мы занесли в триггеры сбоя

Корневая причина сбоя

Не бывает "корневой" причины сбоев. Но люди любят ее искать. На самом деле у сбоев как правило несколько причин и ни одна не бывает важнее других. Сбои как правило это счечение множества обстоятельств. Если вы нашли только одну причину, то скорее всего вы просто недоработали.

Необвинительная (blameless) культура

Большинство причин сбоев так или иначе связаны с людьми. Это даже чувтсвуется интуитивно. Есть соблазн применять универсальную методику починки таких проблем: ругаться, штрафовать и другими способами наказывать за промахи сотрудников. Это действительно дает эффект, так как люди вероятно найдут часть из этих причин и будут стараться избегать подобных случаев. Тем не менее на длительном сроке это работает плохо. Во-первых, это не системная работа и часть улучшений будет только из-за того, что люди временно стали внимательнее. Потом часть из них уволится, часть просто позабудет о ситуации и опять получим такое же количество сбоев по тем же причинам. Но что еще хуже, в такой среде люди начинают вырабатывать альтернативные способы защиты от подобных негативных последствий для себя: сокрытие проблем; выработка схем, как грамотно себя оправдать, как рассказать, что они не виноваты. И подобные механизмы. В результате получаем плохую атмосферу в компании и отсутсвие системной работы над улучшением надежности.

Вместо этого предлагается принять за аксиому, что люди ошибаются и будут ошибаться. При этом признавать ошибки не страшно и не зазорно и не вредит ни материально и репутационно, если при этом ведется системная работа по выявлению причин сбоев и их устранению. Это называется необвинительная культура. Ее надо целенаправленно строить, так как сами по себе люди всегда будут бояться признаваться в ошибках и недоработках. Помогает, когда в ошибках признаются руководители, давая пример остальным. Это верно для любой сферы деятельности, но в SRE это приобретает особую важность.

TODO(d.maslennikov): подобрать пример для каждой причины и триггера